Many computer architectures have Central Processing Units (CPUs), Random Access Memory (RAM), persistent data storage, Input/Output (I/O) transceivers, bus interfaces, and user interfaces. The CPUs retrieve software from their own internal storage, the RAM, and the persistent data storage. The CPUs execute the software to drive the I/O transceivers and user the interfaces. For example, a CPU may retrieve and execute a crypto software application that encrypts and decrypts user data. Some computer architectures have been reduced to a single integrated circuit form factor
Encryption protects data communications by mathematically and logically hashing data with a secret key to generate a hash result. In some encryption examples like digital signatures, a public key may be used to decrypt this hash result and recover the original data. In other encryption examples, the entities share secret keys that are used to encrypt and decrypt the data. Hardware-based encryption embeds most of this crypto processing in hardware circuitry. The circuitry comprises hardware like data registers, logic gates, multiplexers, clocks, and the like. The hardware circuitry can generate random numbers and secret keys, receive and transfer numbers and keys, and use the keys to encrypt and decrypt data. SOC I/O transceivers use hardware-based encryption to communicate over Local Area Networks (LANs) and Wide Area Networks (WANs). The SOC I/O transceivers may also use hardware based encryption for internal security with other SOC components.
Hardware trust entails the physical validation of the computer hardware that is executing computer software. The computer hardware, like a CPU, has an identity code that is shared secret key. A hardware trust server also knows the shared secret key. The hardware trust server issues random number challenges to software that is executing on the computer hardware. The software that is executing on the hardware hashes the random number with the shared secret key to return a hardware trust result to the hardware trust server. The hardware trust server hashes the same random number with the shared secret key to generate the same hardware trust result. If the hardware trust results match, then the software application has hardware trust. The process can be repeated to refresh the hardware trust for the software application.
The hardware trust server may also digitally sign and issue hardware trust certificates to the software application as it achieves and maintains hardware trust. The software application may then share its hardware trust digital certificates with other entities to demonstrate hardware trust by the hardware trust server. The other entities may use a public key for the hardware trust server to decrypt and validate the hardware trust digital certificates for the software application.
Unfortunately, the integration of hardware trust with SOC I/O transceivers that use hardware-based encryption is not yet efficient and effective. The hardware-based encryption complicates hardware trust validation in the SOC. Without hardware trust, a rogue entity may spoof the hardware-based encryption in the SOC I/O transceiver system and gain access to internal SOC components. The problem is especially acute in a Network Function Virtualization (NFV) data communication network that needs to have hardware trust of its Virtual Network Functions (VNFs). The VNFs also need to have hardware trust of other VNFs and user devices.